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Air  Force  Data  System  Design  Center,  Gunter  AFS  AL  36114 

Air  Force  On-line  Data  System,  a generalized  data 
management  system  operating  on  the  Burroughs  B3500 

Base  Automated  Systems  for  Total  Operations 

Base-Level  Automatic  Data  Processing  Equipment  (ADPE) 

Configuration  Analysis  and  Projection  System  (CAPS), 
used  to  prepare  configuration  management  reports 
(future  hardware  and  software  impacts)  for 
each  base-level  data  processing  installation, 
prepared  by  AFDSDC 's  Operations  Research 
Division. 

Contractor  operated  parts  store  supporting  the  vehicle 
maintenance  function  at  base-level 

Composite  document  which  performs  the  functions  of  the 
data  automation  requirement,  data  project  directive, 
and  data  project  plan 

Data  Management  System:  a series  of  file  management 
software  modules 

Data  Processing  Installation 

Direct  Time  Hours:  that  fraction  of  B3500  operating  time 
directly  chargeable  to  functional  data  systems  based  on 
execution  time  of  functional  software  and  time  expended 
by  the  B3500  operating  system  in  direct  support 
of  functional  data  systems. 

Front-end  Processor:  a small  communications  processor 
associated  with  a host  computer 

Military  Airlift  Command  Aircrew  Resource 
Management  System 

Megabytes,  or  millions  of  bytes  of  data  storage  capacity 

Maintenance  Management  Information  and 
Control  System 
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GLOSSARY  (Concluded) 


0LV3500 

- Proposed  implementation  of  on-line  VIMS  to  operate 
solely  on  the  B3500 

OLVDED 

- Proposed  implementation  of  on-line  VIMS  to  operate 
solely  on  a dedicated  minicomputer 

OLVHYB 

- Proposed  implementation  of  on-line  VIMS  to  operate 
on  a hybrid  configuration  including  the  B3500  and 
an  FEP  minicomputer 

OLVP 

- On-line  VIMS  Prototype  System 

OUH 

- Operational  Use  Hour:  for  any  given  B3500  operating  hour, 
the  sum  of  direct  (DTH)  and  prorated  time  (PTH)  accumu- 
lated during  the  hour 

PTH 

- Prorated  Time  Hour:  that  fraction  of  B3500  operating 
time  (charged  on  a prorata  basis  to  functional  systems) 
during  which  the  B3500  operating  system  is  essentially 
idle,  providing  no  direct  processing  support  to  functional 
systems 

R&A 

- Reports  and  Analysis:  a work  center  supporting  the  base- 
level  vehicle  maintenance  function 

SADPR-85 

- Support  of  Air  Force  Automatic  Data  Processing  Requirements 
through  the  1980's  (Technical  Report,  Electronics  Systems 
Division,  AF  Systems  Command,  L.  G.  Hanscom  Field, 

June  1974) 

STALOG 

- System  to  Automate  Logistics  at  the  Base  Level 

WAM 

- Workload  Analysis  Model:  a regression  analysis  model  for 
prediction  and  measurement  of  computer  utilization 
employed  by  AFDSDC's  Operations  Research  Division 
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SECTION  I 


INTRODUCTION 

This  volume  of  ESD-TR-75-301  describes  the  findings  of  an  on-line 
VIMS  prototype  (OLVP)  development  study.  As  discussed  here,  the 
"prototype"  system  is  assumed  to  be  the  first  operational  version 
installed  in  the  field,  the  forerunner  of  more  than  100  similar 
installations  (same  equipment,  similar  software).  The  material 
presented  identifies  and  clarifies  some  development  issues  and 
should,  therefore,  provide  help  to  VIMS  planners  in  their  decision 
whether  or  not  to  move  ahead  with  a prototype,  and  how  to  proceed  if 
prototype  development  is  undertaken. 

Fortunately,  VIMS  functions  today  as  a working  data  system 
operating  on  the  Burroughs  B3500  in  batch  mode.  This  circumstance, 
combined  with  others,  provides  a set  of  practical  constraints  which 
permit  escape  from  a universe  of  unlimited  development  choices. 

Major  factors  are: 

• The  strong  risks  incurred  in  totally  abandoning 
the  B3500  as  the  currently  successful  processor 
of  VIMS  master  files. 

• The  necessity  of  preserving  the  stability  of  batch  VIMS 
software  and  data  products  during,  and  possibly  after, 
transition  to  an  on-line  mode  of  operation.  Periodic  batch 
reports  will  still  be  needed  not  only  for  vehicle 
maintenance  management  but  as  backup  documentation  for  the 
on-line  system. 

• AFDSDC/LGTV 's  desire  for  an  early  on-line  capability 

as  reflected  in  its  planning  for  an  OLVP  implementation  by 
October,  1977. 

• The  imminence  of  a major  base-level  ADPE  (BLADPE)  upgrade 
under  auspices  of  the  BASE-TOP  and  STALOG  programs. 

Current  expectations  call  for  program  planning  to  be 
essentially  completed  by  1977-78.  Such  an  upgrade  might 
involve  replacement  or  significant  enhancement  of  the 
B3500. 

The  findings  of  the  study,  based  on  these  factors,  are  presented 
in  succeeding  sections  which  deal  with  prototype  development 
options,  design  concepts,  preliminary  projections  of  the  prototype's 
B3500  processing  and  storage  requirements  and  on-line  activity,  and 
prototype  development  planning.  It  should  be  noted  that  these 
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aspects  of  the  prototype  system  are  discussed  with  particular 
emphasis  on  daily  operations,  as  opposed  to  weekly/monthly/quarterly 
processing.  It  should  be  noted  as  well  that  although  no  specific 
system  design  recommendations  are  made,  some  extremely  general 
design  concepts  are  defined  in  order  to  examine  their  feasibility. 
Finally,  preliminary  projections  related  to  prototype  performance 
are  based  on  the  best  data  available  during  this  study.  As  better 
data  becomes  available,  the  analysis  techniques  used  here  can  be 
applied  to  refine  projections. 
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SECTION  II 


DEVELOPMENT  OPTIONS 

The  method  used  to  derive  development  recommendations  involves 
definition  of  four  basic  alternatives  which  must  be  evaluated  in 
light  of  several  criteria  of  corresponding  generality. 


BASIC  ALTERNATIVES 

Figure  1 defines  four  alternatives  for  development  of  the  on- 
line VIMS  prototype  and  indicates  some  relationships  among  them. 

Note  that  each  alternative  must  ultimately  deal  with  the  advent  of 
new  base-level  ADPE.  New  BLADPE  may  take  the  form  of  a single  base 
computer,  a central  base  computer  augmented  by  functionally-oriented 
minicomputers,  or  complete  dispersal  of  base  processing  to 
functional  minis.  There  have  also  been  recent  proposals  calling  for 
consolidation  of  base-level  data  processing  in  a small  number  of 
massive  regional  computing  centers.  (SADPR-35:  Support  of  Air  Force 
Automatic  Data  Processing  Requirements  through  the  1980's, 

Electronic  Systems  Division,  Air  Force  Systems  Command,  L.G.  Hanscom 
Field,  June  1974.) 

The  first  alternative  calls  for  no  action  on  prototype 
development  until  new  BLADPE  has  been  specified  in  some  detail. 

This  is  essentially  a non-option  in  view  of  the  constraint  to 
provide  an  on-line  capability  as  soon  as  practically  possible. 
However,  due  to  unforeseen  changes  in  funding,  technical,  or 
institutional  circumstances,  inaction  cannot  be  dismissed  as  a 
possibility. 

The  second  alternative  (0LV3500)  calls  for  an  on-line  prototype 
supported  solely  by  the  B3500.  The  third  alternative  (OLVHYB)  is  a 
hybrid  VIMS  prototype  with  real-time  file  processing  assumed  by  a 
front-end  processor  (FEP)  minicomputer,  and  the  fourth  (OLVDED) 
calls  for  development  of  the  prototype  on  a dedicated  minicomputer 
after  a transitional  implementation  of  OLVHYB. 

NOTE:  The  term  "dedicated"  refers  to  the  equipment's 

relationship  to  on-line  VIMS,  not  to  its  relationship  with  other 
base-level  processors.  It  is  presumed  that  any  minicomputer 
supporting  VIMS  would  be  linked  via  communications  to  other 
computers  to  the  extent  that  data  exchange  or  mutual  back-up 
requirements  would  dictate,  and  that  any  residual  processing 
capacity  could  be  used  to  support  other  elements  of  the  logistics 
community. 
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Figure  1.  Development  Alternatives 


Although  OLVDED  presumes  an  eventual  transition  from  OLVHYB  to 
FEP-only  operation,  such  a transition  would  not  take  place  until 
after  adequate  experience  has  been  gained  with  FEP  equipment,  a new 
operating  system,  and  with  use  of  on-line  VIMS  in  general. 

Note  that  the  specified  development  sequence  begins  with  an 
analysis  of  the  B3500  as  the  prototype  host  computer,  and  that  the 
succeeding  alternative  calls  for  retention  of  some  file  processing 
on  the  B3500.  This  is  an  essentially  conservative  position  based  on 
the  hope  that  much  of  today's  batch  VIMS  software  can  be  used  to 
support  the  on-line  version  of  the  system.  Use  of  current  software 
is  highly  desirable  because  it  would 

• Lessen  the  expense  and  technical  risk  incurred  in  the  on- 
line system  implementation  effort, 

• Reduce  the  possibility  of  damage  to  VIMS  data  bases, 

• Preserve  the  continuity  of  proven  batch  data  products,  and 

• Assure  availability  of  updated  VIMS  master  files  for  use  in 
batch  mode  as  back-up  in  event  of  on-line  system  failure. 

("Design  Concepts",  Section  III,  describes  a hybrid  file 
configuration  which  could  permit  retention  of  some  current  VIMS 
software) . 

The  arrows  leading  from  alternative  to  alternative  in  Figure  1 
indicate  a progression  of  analysis  and  preliminary  system  design, 
with  arrival  at  any  one  choice  dependent  upon  evaluation  of  each  of 
the  preceding  alternatives.  Such  analyses  require  use  of  evaluation 
criteria: 

• Performance 

• Cost 

• Technical  Risk 

Whatever  prototype  development  strategy  is  selected,  the 
decision  must  be  based  on  an  acceptable  balance  of  cost, 
performance,  and  technical  risk,  including  the  probable 
compatibility  of  the  prototype  implementation  with  future  BLADPE. 


EVALUATION  CRITERIA 

Performance  - The  performance  criterion  is  concerned  with  the 
timeliness  with  which  the  on-line  system  responds  to  user  commands. 
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Because  of  the  data  management  (as  opposed  to  computational) 
orientation  of  on-line  VIMS,  system  performance  will  equate  to  file 
access  performance.  Some  of  the  time  expended  in  file  processing  is 
keyed  to  storage  device  performance  (disk  latency,  transfer  rate). 

By  far  the  greatest  access  delays  are  encountered,  however,  during 
the  time  an  individual  read/write  request  must  wait  enqueued  until 
prior  requests  have  been  serviced.  This  means  that,  equipment 
performance  factors  being  equal,  the  less  software  contention  for 
storage  access  the  faster  the  rate  of  access  for  any  particular 
software  system. 

Cost  - "Prototype  Development  Planning",  Section  V,  presents  the 
method  used  to  estimate  costs  of  the  three  development  options.  As 
one  might  suspect,  development  program  costs  vary  directly  with  the 
amount  and  complexity  of  new  prototype  software  which  must  be 
written. 


Technical  Risk  - The  degree  of  technical  risk  presented  by  each 
alternative  equals  the  extent  to  which  its  successful  implementation 
is  threatened  by  technical  complexities  and  unknowns.  There  seem  to 
be  two  separate  sources  of  risk:  difficulty  of  transition  to  new 

BLADPE,  and  the  relative  magnitude  of  new  equipment  and  software  to 
be  incorported  in  the  protoype  configuration. 


CRITERIA  APPLIED 

Table  I summarizes  the  evaluation  of  development  options  in 
light  of  the  criteria  defined  above. 

Performance 


0LV3500  performance,  although  potentially  acceptable  (and 
currently  unknown)  would  be  poorer  than  that  provided  by  the  other 
alternatives  since  VIMS  software  would  have  to  compete  with  other 
B3500  users  for  file  access  facilities.  (This  would  be  the  case 
unless  VIMS  were  provided  with  a dedicated  on-line  storage  device 
and  data  channel.)  Given  an  FEP  to  process  "on-line"  files, 
performance  of  OLVHYB  would  be  superior  to  that  of  0LV3500  since 
contention  with  other  systems  for  storage  access  would  occur  only  in 
the  B3500.  Use  of  a dedicated  minicomputer  would  further  reduce 
contention  by  non-VIMS  software. 

In  the  absence  of  a system  design,  the  performance  baseline 
represented  by  OLV35O0  is  currently  inestimable.  Once  a rough 
design  is  postulated,  however,  the  number  of  random  access 
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Table  I 


Evaluation  of  Development  Options 


\cRITERIA 

OPTIONS 

ESTIMATED 

PERFORMANCE 

TECHNICAL 

RISK 

ESTIMATED 

DEVELOPMENT 

COST 

SYSTEM 

DEVELOPMENT 

TRANSITION  TO 
NEW  BLADPE 

BATCH 

MODE 

VIMS 

- 

- 

? 

- 

OLV3500 

? 

(until  Prelim- 
inary design) 

LEAST 

? 

$ . 5M 

OLVHYB 

BETTER 

MORE 

? 

$1 . OM 

OLVDED 

BEST 

MOST 

? 

$1.5M 

read/write  operations  per  transaction  type  will  be  established,  and 
these,  multiplied  by  projected  transaction  volumes,  can  then  yield 
total  storage  accesses  per  some  unit  time.  Matched  against  current 
B3500  response  time/storage  access  baselines  for  other  on-line 
systems,  these  figures  will  provide  some  clue  to  probable  0LV3500 
performance.  Related  preliminary  projections  are  included  in 
Section  IV. 


Technical  Risk 


Development  risk  increases  with  use  of  unfamiliar  equipment  and 
system  software,  the  requirement  to  write  and  test  new  application 
software,  and  the  decision  to  abandon  use  of  proven  software. 
Hopefully,  risk  associated  with  an  OLVDED  implementation  would  be 
minimized  through  the  familiarity  with  new  equipment  and  software 
gained  during  the  OLVHYB  experience. 

The  characteristics  of  new  BLADPE  are  currently  unknown. 

However,  the  closer  the  similarity  of  system  architectures  (OLVP- 
BLADPE),  the  easier  the  transition.  On-line  VIMS  designers  should 
have  some  hints  as  to  the  new  BLADPE  configuration  prior  to 
specifying  the  prototype's  final  architectural  details. 

Beyond  architecture,  ease  of  transition  depends  heavily  on  the 
language  facilities  to  be  employed  with  new  equipment.  For  example, 
should  OLVHYB  be  implemented  in  COBOL  on  both  the  B3500  and  FEP, 
transition  to  a base  computer  plus  functional  mini  (if  a mini 
transition  were  needed)  would  be  greatly  aided  if  COBOL  were 
available  on  the  new  machine(s).  (Plans  are  currently  being 
advanced  within  DOD  to  develop  a universal  minicomputer  COBOL 
compiler  compiler.) 

Cost 


"Prototype  Development  Planning",  Section  V,  contains  a detailed 


breakdown  of  costs 

by  development 

option  by 

program  year 

Summarized,  these 

are : 

Manpower 

Equipment 

Total 

Costs 

Costs 

Costs 

0LV3500 

$ 395,200 

$ 12,000 

$ 407,200 

OLVHYB 

$ 904,800 

$112,000 

$1,016,800 

OLVDED 

$1,320,800 

$112,000 

$1,432,800 
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CONCLUSIONS 


An  OLV3500  prototype  appears  cheapest  and  least  risky  to 
develop,  but  its  performance  will  be  unknown  until  a preliminary 
system  design  is  completed,  as  indicated  above.  If  0LV3500 
performance  is  eventually  projected  as  marginal  or  unacceptable, 
then  OLVHYB  should  be  considered  as  a means  to  relieve  the  B3500  of 
most  real-time  file  processing.  This  would  then  leave  the  option 
open  to  progress  to  OLVDED  for  ease  of  transition  to  new  BLADPE,  or 
for  other  reasons. 

Presuming  OLV3500  performance  is  judged  adequate,  cost  and 
technical  risk  factors  must  be  inspected.  If  either  of  these  is 
unacceptable,  (with  OLVHYB  and  OLVDED  offering  progressively  higher 
cost  and  technical  risk),  then  there  seems  to  be  no  choice  but  to 
await  specification  of  new  BLADPE  while  operating  VIMS  in  standard 
batch  fashion.  If  cost  and  technical  risk  are  acceptable,  then 
OLV3500  has  qualified  as  an  alternative  and  the  decision  must  be 
made  to  either  move  ahead  with  an  OLV3500  implementation  or  to 
qualify  OLVHYB  as  another  candidate  through  analysis  and  preliminary 
design. 
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SECTION  III 


DESIGN  CONCEPTS 

The  following  subsections  provide  general  descriptions  of  data 
file  configurations,  equipment,  and  software  which  might  be 
incorporated  in  each  of  the  three  prototype  implementations. 


HYBRID  FILE  CONFIGURATION 

Both  OLV3500  and  OLVHYB  would  incorporate  B3500-based  master 
file  processing  and  retention  of  the  current  end-of-day  batch  run 
for  the  following  reasons: 

• An  implementation  effort  utilizing  existing,  checked-out 
software  appears  faster,  cheaper,  and  less  technically 
risky  than  a complete  redesign  and  implementation. 

• Utilization  of  current  batch  software  to  the  extent 
possible  would  reduce  risk  of  damage  to  VIMS  data  bases  and 
would  therefore  preserve  the  continuity  of  proven  batch 
products,  many  of  which  would  still  be  required  by  VIMS 
users  after  on-line  services  were  available,  independent  of 
the  implementation  strategy  selected. 

• Retention  of  the  B3500  batch  run  would  assure  availability 
of  updated  master  files  for  use  in  a batch-only  mode  as  a 
back-up  measure  in  event  of  major  on-line  equipment  or 
software  failure. 

Given  retention  of  as  much  of  the  current  VIMS  batch  software  as 
possible,  a functional  distinction  must  be  made  between  the  batch 
run  master  files,  to  be  accessed  in  "read-only"  mode  during  on-line 
operations,  and  a second  set  of  on-line  files:  master  file  subsets 
and  update  transaction  files.  These  latter  would  be  processed  in 
normal  read/write  mode  during  the  on-line  day  and  would  be  post- 
processed  to  create  update  input  tailored  for  the  batch  run.  With 
0LV3500,  the  functional  distinction  between  master  and  on-line  files 
would  be  maintained,  although  both  sets  would  be  processed  by  the 
single  computer.  Under  OLVHYB,  the  FEP  minicomputer  would  process 
the  on-line  files,  with  master  file  processing  retained  on  the 
B3500.  Both  sets  of  files  would  be  processed  by  the  former  FEP 
under  OLVDED. 

Separation  of  master  and  on-line  files  would  provide  well- 
defined  interfaces  to  the  system  designers  who  must  specify  the  on- 
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line  VIMS  monitor,  command  language  processor,  transaction  manager, 
and  file  manager.  (These  pieces  of  software  would  have  to  be 
developed  in  any  case  regardless  of  data  base  locations.)  As  well, 
separation  of  files  would  simplify  the  analysis  needed  to  support 
the  decision  for  or  against  use  of  a generalized  data  management 
system.  It  also  makes  sense  to  leave  VIMS  master  file  processing 
functions  in  COBOL-based  software  for  ease  of  hardware  transition  to 
new  BLADPE. 

Figure  2 indicates  some  suggested  major  relationships  among 
"master”  files  and  their  pre-processed  input  files,  and  "on-line" 
files  which  would  be  directly  accessible  to  the  prototype  on-line 
VIMS  system  during  normal  working  hours.  (Obviously,  a category  of 
supporting  files  has  been  omitted  here:  file  indices,  executable 

software  elements,  file  management  catalogs,  message 
logging/accounting  files,  I/O  spooling  files,  scratch  files,  and 
others. ) 

Under  an  OLVHYB  development  plan,  the  files  designated  "end-of- 
day  batch"  would  be  processed  initially  by  the  B3500,  to  be 
transferred  in  a subsequent  OLVDED  implementation  to  the  FEP  which 
would  initially  process  only  the  on-line  files.  Under  0LV3500  all 
files  would  be  processed  by  the  B3500. 

Regardless  of  how  the  various  on-line  files  might  be  associated 
with  processors,  the  decision  to  retain  a VIMS  end-of-day  batch  run 
would  require  that  several  kinds  of  modifications  be  made: 

1.  Addition  of  batch  pre-processing.  In  order  to  use  existing 
batch  file  update  software  to  the  maximum  extent  possible, 
the  content  of  the  on-line  "transaction"  files  must  be 
reformatted  prior  to  processing  during  the  batch  run. 

These  include  the  Vehicle  Update,  Work  Order,  Deferred 
Maintenance,  and  Employee  Transaction  files. 

2.  Changes  to  batch  run  input  routines  such  that  pre-processor 
output  can  be  accepted  in  addition  to  the  current  classes 
of  input  files. 

3.  Addition  of  batch  post-processing  to  regenerate  on-line 
files  for  the  next  day's  operation.  These  files  include 
the  Vehicle,  Work  Order,  and  Employee  subsets,  and  the 
Deferred  Maintenance,  and  High  Cost  Bench  Stock  files. 

4.  Addition  of  update  processing  to  the  current  batch  run 
required  by  new  on-line  prototype  files.  These  are  the 
Vehicle  Historical  Repair,  Back-Ordered  Parts,  and  Parts 
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Figure  2.  Hybrid  File  Configuration 


18 


ON-LINE 


END-OF-DAY  BATCH 


Updated 


Deferred  . 
Maintenance 
tMaster 


Updated 

fEmployee 

Master 


Updated 


[High  Cost 
Bench  Stock  ( £■ 
LMaster 


/Pre  proce  ssed f 
Batch  InputsK 


Preprocessed  I 
Batch  Inputsl-f- 


Initially  Void 
Read/wr  ite 

f Deferr ed 
Maintenance 
VTransactionsl 


Read-only 

deferred 
_^j  Maintenance 


kFile 


Initially  Void 
Read/write 

fEmployee  / 
Transactions 


Read-only 


Employee 
.^Subset 


Read-only 

fHigh  Cost 
Bench  Stock 
IFile 


Figure  2.  Hybrid  File  Configuration  (Continued) 
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Figure  2.  Hybrid  File  Configuration  (Concluded) 


Warranty  files  plus  COPARS  sales  transactions  (for 
Accounting  and  Finance). 

5.  Changes  to  existing  batch  file  update  routine  required  by 
expanded  file  content  (such  as  the  addition  of  job-specific 
data  items  to  the  Work  Order  and  Deferred  Maintenance 
files). 


EQUIPMENT  COMPONENTS,  CONFIGURATIONS 

The  intent  to  proceed  with  prototype  development  from  a base  of 
proven  technology  (VIMS  batch  software  operating  on  the  B3500) 
limits  equipment  configuration  options  to  combinations  of  the 
following  components: 

• B3500  processor  and  associated  auxiliary  storage  (disk) 

• Basic  terminal:  CRT/keyboard  with  hardcopy  printer 

• Enhanced  terminal:  Basic  terminal  enhanced  by  addition  of  a 
programmable  processor  and  auxiliary  storage. 

• Front-end  Processor  (FEP)  communicating  with  the  B3500 
either  dedicated  to  transportation  or  shared  by  multiple 
on-line  systems. 

• Disk  file  controller  modified  to  permit  sharing  of  B3500 
auxiliary  storage  with  an  FEP.  (The  disk  sharing  feature 
is  available  from  Burroughs  at  extra  cost.) 

For  a number  of  reasons  (explored  below),  best  combinations  of 
components  for  each  prototype  implementation  seem  to  be: 

(OLV3500) 

B3500,  associated  disk  storage,  basic  terminals 
(OLVHYB) 

B3500  and  FEP,  each  with  associated  disk  storage,  basic 
termi nals 


(OLVDED) 

Minicomputer,  disk  storage,  basic  terminals 

Further,  OLVDED's  minicomputer  would  be  the  same  as  OLVHYB's 
FEP,  possibly  enhanced  by  a larger  memory  and  more  disk  storage, 
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since  the  OLVDED  alternative  would  probably  be  developed  via  a 
transitional  implementation  of  OLVHYB. 

Note  that  these  configurations  are  the  simplest  possible  of  many 
potential  conbinations  of  components.  These  were  selected  because 
of  ease  of  relative  comparison  and  because  they  seem  capable  of 
performing  the  prototype  mission.  This  is  not  to  say  that  there  are 
no  potential  advantages  in  the  use  of  shared  disk  storage  or 
enhanced  terminals. 

Like  the  FEP,  an  enhanced  terminal  could  provide  useful  pre- 
processing services  to  the  on-line  VIMS  system: 

• Real-time  edit  checks  and  on-line  error  correction  of  input 
transactions. 

• Local  storage  and  transfer  of  screen  formats  used  with  the 
CRT  terminals. 

In  addition  to  its  on-line  pre-processing  role,  the  enhanced 
terminal  could  perform  as  a transaction  concentrator  during  periods 
of  B3500  outage  or  saturation.  If  the  terminal  is  to  perform 
extensive  editing  of  input  transactions  it  must  have  available  to  it 
some  subset  of  the  VIMS  master  files,  and  this  subset  must  be 
strictly  synchronized  in  content  with  the  files  processed  by  the 
other  coraputer(s).  This  would  incur  some  measure  of  overhead 
processing  and  would  introduce  another  element  of  risk.  As  well, 
location  of  large  on-line  files  at  the  terminal  might  require  use  of 
disk  drives  needing  more  controlled  environmental  conditions  (air 
conditioning/cleaning,  vibration  suppression)  than  could  be  provided 
by  many  vehicle  maintenance  offices.  Enhanced  terminals  could  offer 
more  rapid,  seemingly  instantaneous  response  to  an  operator,  than 
basic  terminals  remote  from  a minicomputer.  The  two  become 
functionally  equivalent,  however,  with  "adequate"  communications 
bandwidth  between  the  basic  terminal  and  the  minicomputer;  adequate 
bandwidth  is  a function  of  the  particular  application,  and  is 
probably  2400  bps  for  OLVP.  If  advanced  interactive  techniques 
involving  light-pen  selection  from  rapidly  changing  display  formats 
were  to  be  used  for  VIMS,  required  bandwidth  would  probably  have  to 
be  much  greater.  Such  techniques  might  be  explored  for  future 
enhancements  to  on-line  VIMS. 

Sharing  B3500  disk  storage  with  an  FEP  would  provide  the 
following  advantages:  on-line  VIMS  software  could  access  all  files 
directly  (both  master  and  update  transaction  files)  without 
incurring  idle  time  waiting  for  requests  to  clear  B3500  I/O  queues, 
although  some  waiting  would  take  place  when  access  conflicts  arose 
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(disk  busy  with  B3500  I/O  operation);  B3500-resident  VIMS  software 
might  be  reduced  by  that  amount  needed  to  perform  file  processing 
(during  the  on-line  period);  the  FEP  could  lend  some  pre/post 
processing  support  to  the  B350O  batch  run;  VIMS  could  remain  on-line 
during  some  classes  of  B3500  failure,  maintaining  access  to  data; 
shared  disk  would  provide  an  alternate  communication  path  with  the 
B3500  which  could  be  used  should  the  primary  path  (communication 
line,  I/O  channel,  etc.)  fail. 

It  appears  that  these  advantages  are  heavily  outweighed  by  the 
following  penalties:  one  of  the  processors,  B3500  or  FEP,  would 
remain  roadblocked  and  idle  until  the  other  released  the  shared  disk 
(presuming  a software-controlled  request/release  feature  at  the  disk 
controller  level);  I/O  control  software  operating  in  the  B3500  would 
have  to  be  rewritten  to  incorporate  request/release  statements;  disk 
control  hardware  would  have  to  be  acquired  (an  extra  cost  feature*); 
choice  of  an  FEP  would  be  restricted  to  a processor  which  could 
support  the  signalling  protocols  used  with  the  shared  disk 
controller;  use  of  shared  disk  would  heighten  the  complexity  of  the 
overall  configuration,  software  interfaces,  and  check-out 
procedures,  and  would  increase  the  total  technical  risk  incurred 
during  development. 


SOFTWARE 

Ignoring  some  duplication,  roughly  the  same  classes  of  software 
elements  will  be  required  by  each  of  the  three  prototype  development 
alternatives.  Listed  below  are  software  elements  as  they  would  be 
allocated  to  processors  in  the  OLVHYB  configuration.  Note  that 
OLV3500  calls  for  all  software  to  operate  on  the  B3500,  and  that  the 
transition  from  OLVHYB  to  OLVDED  requires  a rewrite  of  B3500- 
resident  software  as  its  functions  are  assimilated  by  the  FEP.  A 
decision  would  have  to  be  made  at  this  point  whether  to  retain 


* Note:  Equipment  rental  costs  would  exceed  $1,000  per  installation 
per  month  using  a one  year  lease  pricing  schedule. 
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current  data  structures  and  master  file  processing  logic  or  whether 
to  redesign  these  for  optimized  efficiency  with  the  FEP  (presuming 
optimization  appears  possible). 

OLVHYB  SOFTWARE  ELEMENTS 

(presuming  operating  system  support  of  job  scheduling,  interrupt 
servicing,  and  program  language  processing  functions.) 

B^OO- RESIDENT 

• On-line  VIMS  file  manager,  to  accept  and  process  master 
file  access  requests  transmitted  from  the  FEP 

• Current  batch  file  processors,  modified  as  indicated  below 

• Batch  run  pre-processor 

• Batch  run  post-processor 

FEP-RESIDENT 

• VIMS  executive,  to  perform  status  posting,  task  scheduling, 
communications  logging,  recovery  checkpointing  and  similar 
functions 

• Command  analyzer  and  command  processors,  to  respond  to  user 
input  commands 

• Terminal  device  drivers 

• Transaction  manager  and  edit  routines  (with  some  edit  logic 
borrowed  from  the  current  batch  run) 

• File  manager,  to  perform  logical  file  I/O  to  the  extent 
this  function  is  not  provided  by  the  operating  system 

• File  loader/structurer  for  daily  file  up-loads 

• System  and  file  recovery  modules 

• Report  generators,  to  produce  on-line  traffic  analyses, 
file  activity  reports,  etc. 

With  individual  software  tasks  defined,  it  is  appropriate  to 
question  whether  or  not  a generalized/centralized  data  management 
system  could  assume  the  functions  of  multiple  software  elements  with 
some  savings  in  implementation  costs  and  manpower.  Typical 
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commercially  available  DMS's  provide  some  or  all  of  the  following 
facilities: 

• Self-contained  data  access  and  update  languages. 

• Data  access  and  update  services  which  may  be  invoked 
through  a "host"  programming  language  such  as  COBOL. 

• A file  structuring  capability  which  provides  some  measure 
of  software  independence  from  data  structure  detail. 

• An  on-line  transaction  routing  and  filing  capacity. 

• A generalized  input  data  edit  and  file  conversion 
capability. 

• A data  base  checkpoint  and  recovery  capability. 

• Facility  for  collection  of  operational  usage  and 
performance  statistics. 

Availability  of  a commercially-proven,  seasoned  DMS  could  be  a 
strong  point  in  favor  of  candidate  FEP  equipment  when  planning  for  a 
hybrid  implementation  of  the  on-line  VIMS  prototype.  (Less  elaborate 
data  management  aids  such  as  file  access  methods  and  higher  level 
languages  are  readily  available  for  use  on  minicomputers.  For 
example,  a COBOL  subset  compiler  for  a mini  can  be  purchased  today 
for  less  than  $3,000.)  Because  of  the  potential  complexity  of  DMS 
software,  it  cannot  be  stressed  too  strongly  that  any  such  system 
procured  should  have  been  exercised  over  a period  of  time  on  a wide 
variety  of  applications  to  ensure  identification  and  repair  of 
residual  program  errors.  A commercial  DMS  is  preferable  to  "free" 
government-owned  systems  since  the  latter  typically  suffer  from  a 
lack  of  adequate  documentation,  and  because  their  performance  and 
maintenance  are  not  ensured  by  any  sort  of  enforceable  contract 
leverage. 

Beyond  software  stability,  the  following  criteria  should  be 
applied  to  a DMS  in  evaluating  it  for  a possible  role  in  a VIMS 
prototype: 

• Basic  DMS  costs,  which  might  range  from  zero  to  hundreds  of 
dollars  per  month  per  installation  (presuming  an  on-going 
software  maintenance  and  enhancement  service) 
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• DMS  capabilities  directly  useful  to  on-line  VIMS  prototype 
processing  and  cost  of  acquiring  capabilities  not  provided 
by  the  DMS 

• Extent  and  costs  of  modifications  to  VIMS  or  the  DMS 
required  to  achieve  satisfactory  interfacing. 

In  considering  the  role  of  a DMS  in  an  OLV3500  implementation  it 
is  necessary  to  analyze  the  potential  capabilities  and  liabilities 
of  the  Air  Force  On-Line  Data  System  (AFOLDS)  as  developed  by  AFDSDC 
since  it  is  apparently  the  only  generalized/centralized  DMS 
currently  operating  on  the  B350O.  Those  responsible  for  the  design 
of  the  on-line  VIMS  prototype  should,  before  making  any  decision  as 
to  AFOLDS'  role  in  their  planning,  attempt  to  answer  the  following 
questions: 

• Is  AFOLDS  software  stable  to  the  point  where  it  will  not 
compound  the  recognized  danger  of  VIMS  software 
modification? 

• Does  use  of  AFOLDS'  data  management  services  require 
additional  changes  to  VIMS  software  in  any  major  way?  What 
are  the  risks  and  costs  of  modification?  The  OLVP  user 
interface  as  presently  specified  (and  as  verified  during 
model  test)  relies  heavily  on  use  of  source  documents  and 
video  presentations  of  source  documents  currently  utilized 
by  transportation  maintenance  personnel..  The  on-line  VIMS 
"language"  is  therefore  not  generalized  in  the  fashion  of 
the  AFOLDS  languages  used  for  data  retrieval  and  update. 
OLVP  use  of  AFOLDS  facilities  would  require  implementation 
of  translator  software. 

• Should  the  VIMS  on-line  prototype  design  and  implementation 
be  keyed  to  AFOLDS  data  management  services,  how 
transferable  is  the  AFOLDS  software  to  the  non-B3500 
processors  to  be  used  following  transition  to  new  base- 
level  ADPE? 

In  sum,  data  management  systems  can  provide  an  assortment  of 
highly  useful  data  manipulation  services  and  can  potentially  reduce 
system  implementation  schedules.  In  fact,  in  the  case  of  an  OLVHYB 
or  OLVDED  implementation,  availability  of  a proven  DMS  on  a 
particular  equipment  model  could  weigh  heavily  in  its  favor  in  the 
equipment  selection  process.  Use  of  an  unproven  DMS,  however,  would 
invite  serious  system  development  problems. 
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SECTION  IV 


PRELIMINARY  PROJECTIONS 

The  following  subsections  present  brief  analyses  projecting  the 
prototype's  requirements  for  B3500  processing  support  and  data 
storage,  and  the  on-line  transaction  activity  that  might  be 
anticipated.  These  analyses  were  prepared  using  the  best  data 
available,  essentially  no  more  exact  than  best  estimates  from  a 
range  of  sources.  As  the  quality  of  projected  data  improves  (B3500 
workload  baseline,  OLVP  data  structures,  etc.)  the  same  methods  may 
be  used  to  develop  more  exact  results. 


B3500  WORKLOAD 

Presuming  the  possibility  of  a B3500-based  on-line  VIMS 
prototype,  it  becomes  important  to  project  system  workloads  in  order 
to  assess  impact  on  computer  resource  demand.  The  issue  is 
straightforward:  will  addition  of  on-line  VIMS  processing  saturate 
the  capacity  of  any  B3500  DPI's  during  the  daily  on-line  period? 

Ideally,  one  would  make  a judgement  after  comparing  projected 
VIMS  resource  demands  against  residual  resources  remaining  above  a 
demand  baseline  computed  for  the  on-line  shift.  This  is  a 
simplistic  process  and  potentially  a misleading  one  since,  in  the 
absence  of  an  instantaneous  resource  baseline,  resource  demands  must 
be  arbitrarily  smoothed  across  the  daily  on-line  shift.  The  actual, 
and  largely  randomly-occurring,  demand  peaks  and  valleys  are  thereby 
lost.  Confidence  in  the  results  of  the  workload  projection  task 
must  be  tempered  with  the  knowledge  that  where  there  is  a 
coincidence  of  demand  by  VIMS  and  by  competing  on-line  systems, 
response  time  of  all  systems  must  degrade. 

Using  the  methods  described  below,  it  was  found  that  on  a 
monthly  basis,  addition  of  on-line  VIMS  processing  would  increase 
the  B3500  operational  use  hours  (OUH)  expended  at  20  sample  bases  by 
an  average  of  six  percent.  On  a daily  basis  (on-line  shift),  VIMS 
would  increase  the  OUH  processing  load  by  six  to  31  precent  at  24 
sample  bases.  The  significance  of  these  estimates  will  become 
evident  as  the  methods  of  estimation  are  described.  The  following 
list  provides  an  overview  of  the  estimation  process  and  a guide  to 
the  following  text.  (Source  calculations  appear  in  Appendix  I). 

1)  Relationships  between  fleet  size  and  monthly  transaction 

volumes,  and  between  B3500  direct  time  hours  (DTH)  and  disk 
I/O  volumes  were  confirmed. 
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2)  Numbers  of  disk  I/O's  were  assigned  to  on-line  VIMS 
transaction  types. 

3)  Total  monthly  disk  I/O's  for  nine  sample  bases  were 
calculated  using  volumes  of  batch  transactions 
corresponding  to  on-line  VIMS  transactions. 

4)  Monthly  I/O's  were  converted  to  monthly  DTH. 

5)  Fleet  size  was  related  to  monthly  direct  time  hours,  and 
monthly  and  daily  DTH  were  projected  for  20  and  24  sample 
bases. 

6)  Monthly  and  daily  DTH  were  converted  to  OUH  and  impact  on 
current  workloads  was  analyzed. 

The  objective  of  the  workload  projection  effort  was  to  construct 
a method  by  which  on-line  VIMS  prototype  demands  for  B3500  computer 
time,  a dependent  variable,  could  be  estimated  for  any  DPI  using  an 
independent  variable.  Vehicle  fleet  size  was  the  independent 
variable  chosen  because  of  its  easy  availability  as  a data  item  and 
because  of  its  assumed  high  correlation  with  monthly/daily  VIMS 
transaction  volumes.  It  was  assumed  in  turn  that  computer  time 
requirements  would  vary  directly  with  transaction  volumes. 

By  convention,  B3500  computer  time,  expressed  in  operational  use 
hours,  is  made  up  of  two  components:  direct  time  hours  (DTH),  that 
fraction  of  time  during  which  work  is  being  done  by  or  for  specific 
data  systems,  and  prorated  time  hours  (PTH),  that  remaining  fraction 
which  is  overhead  time  not  chargeable  to  specific  systems  yet 
assigned  to  all  on  a prorated  basis  as  a function  of  the  job  mix. 

Of  these  categories  of  processing  time,  DTH  most  closely  reflects 
the  "real"  computer  time  requirements  of  data  systems,  since  both 
PTH  and  OUH  are  tied  to  transient  conditions  of  the  job  mix.  What 
is  needed,  then,  is  a reliable  predictor  of  DTH  which  could  also  be 
tied  to  vehicle  fleet  size. 

As  it  turns  out,  DTH  varies  closely  and  directly  with  numbers  of 
physical  disk  reads  and  writes  on  the  B3500.  Given  these 
relationships,  a method  was  developed  whereby  numbers  of  physical 
disk  I/O's  were  arbitrarily  assigned  to  the  various  on-line  VIMS 
transaction  types,  numbers  of  on-line  transactions  were  predicted 
using  today's  volumes  of  batch  transactions  (tied  to  fleet  sizes  at 
nine  bases),  and  the  disk  I/O's  thus  projected  on  a monthly  basis 
were  converted  to  monthly  DTH.  Regression  equations  were  then 
developed  expressing  the  relationship  of  fleet  sizes  to  monthly  DTH 
workloads  at  the  sample  bases. 
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By  convention,  however,  DPI  saturation  occurs  when  OUH  required 
exceeds  OUH  available,  so  some  means  of  DTH-to-OUH  conversion  was 
needed.  Since  B3500  accounting  software  monitors  both  DTH  and  PTH, 
the  "percent  direct"  component  may  be  computed  for  an  OUH  total. 

The  conversion  factor  (developed  from  a month's  worth  of 
observations  at  24  sample  DPI's)  was  then  used  to  inflate  monthly 
DTH  values  to  monthly  OUH. 

Several  regression  equations  were  developed  based  on  data 
collected  from  separate  sources.  There  were  five  equations  in  all, 
derived  from: 

(1)  Observed  VIMS  batch  processing,  24  sample  bases,  June,  1974 
(provided  by  AFDSDC/SYO) 

(2)  As  above,  incorporating  July,  1974  data 

(3)  A disk  I/O-DTH  conversion  factor  borrowed  from  AFDSDC's 
Workload  Analysis  Model  (WAM) 

(4)  A disk  I/O-DTH  conversion  factor  developed  from  batch  VIMS 
processing  data 

(5)  A disk  I/O-DTH  conversion  factor  developed  from  current  on- 
line system  observations. 

All  five  equations  relate  monthly  DTH  to  fleet  size:  the  first 
two  were  developed  directly  from  fleet  and  DTH  data,  the  last  three 
were  prepared  using  the  intermediate  conversion  of  projected 
transactions-to-disk  I/O's-to-DTH. 

Despite  the  diverse  origins  of  the  equations,  their  corres- 
ponding regression  lines  are  not  wildly  dispersed.  (See  Appendix 
I).  A maximum  and  minimum  monthly  DTH  (against  fleet  size)  envelope 
was  drawn  outside  the  group  of  regression  lines  and  the  extreme 
values,  lying  along  the  envelope's  boundaries,  were  used  to 
construct  monthly  and  daily  analyses.  The  results  of  these  were  as 
reported  above:  a projected  six  percent  rise  in  monthly  OUH  workload 
at  20  sample  bases,  and  a daily  OUH  increase  of  from  six  to  31 
percent  projected  for  24  sample  bases.  Given  the  extreme  values 
used  in  the  analyses,  the  following  conclusion  appears  reasonable: 

To  the  extent  that  the  monthly  and  daily  resource  demand 
baselines  can  be  trusted  as  reasonably  accurate,  and  in  the 
absence  of  additional  high  activity  on-line  systems  in  the 
future,  it  appears  that  the  operation  of  an  on-line  VIMS 
prototype  will  not  dangerously  threaten  saturation  of 
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B3500  resources  during  the  on-line  shift  except  at  those 
DPI's  requiring  upgrade  which  operate  today  in  a condition 
of  marginal  saturation. 


B3500  DISK  STORAGE 

Presuming  a functional  split  between  VIMS  "master"  files  and  the 
"on-line"  files,  we  are  concerned  about  the  storage  capacities 
(expressed  in  megabytes)  required  for  each  class.  The  following 
tables  summarize  the  results  of  a brief  on-line  VIMS  disk  storage 
analysis. 

Table  II  shows  OLVP  disk  storage  requirements  in  megabytes  for 
each  of  three  arbitrary  fleet  size  categories  as  established  for  a 
sample  of  2 4 bases.  Note  that  segregation  of  master  and  on-line 
files  by  processor  would  occur  only  with  OLVHYB.  For  the  other 
alternatives  the  storage  total  would  apply  to  a single  processor 
(B3500  or  minicomputer). 


Table  II 

On-Line  VIMS  Prototype  Disk  Storage  Requirements 


Fleet 

Size 

No. 

Bases 

Master  Files 
MB  Disk 
B3500 

On-Line  Files 
MB  Disk 
FEP 

Total 

1 191-752 

6 

10.4 

2.6 

13.0 

744-466 

1 1 

7.1 

1.8 

8.9 

447-235 

7 

3.8 

1.0 

4.8 

Using  fleet  size  as  an  entering  argument,  B3500  requirements 
were  taken  directly  from  the  DAR-DPD-DPP  for  on-line  VIMS 
(AFDSDC/LG,  16  December  1974).  FEP  figures  for  each  base  were 
calculated  by  multiplying  the  B3500  master  file  allocations  by  .25 
to  account  for  subset  and  transaction  files.  These  results  seem 
reasonable  in  view  of  the  correspondingly  larger  storage 
requirements  of  higher  activity  on-line  systems.  (MMICS  operation 
requires  from  14.4  MB  to  69.6  MB  of  disk  storage  depending  upon 
forecasted  base  activity.) 
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Using  CAPS  Report  Number  Nine,  a disk  storage  projection  current 
to  June,  1976  was  constructed  for  each  sample  base  and  the 
calculated  OLVP  requirements  were  added  to  this  baseline  in  each 
case.  The  results  are  summarized  in  Table  III. 

Table  III 


DISK  STORAGE  REQUIRMENT  SUMMARY 
24  SAMPLE  BASES 

Disk  Saturation  Projected  (June,  1976) 


Without  On-Line  VIMS 

25$  (6  DPI's) 

Max  Disk  Deficit 

7.7  MB 

Avg  Disk  Deficit 

4.9  MB 

Total  Saturated  After  Addition  Of 
On-line  VIMS 

54$  (13  DPI's) 

Saturated  Due  Only  To  On-line  VIMS 

29$  (7  DPI's) 

Max  Disk  Deficit  (Incl  On-line  VIMS) 

16.6  MB 

Avg  Disk  Deficit  (Incl  On-line  VIMS) 

8.2  MB 

Max  On-line  VIMS  Disk  Requirement 

13.0  MB 

Avg  On-line  VIMS  Disk  Requirement 

8.8  MB 

Active  AF  Bases  (June,  1974) 

103 

DPI's  Potentially  Saturated 
Due  To  OLVP 

30 

The  picture  presented  in  Table  III  could  be  somewhat  misleading 
because: 

• Planned  upgrades  to  disk  capacities  (based  on  CAPS 
projections)  will  no  doubt  have  been  made  prior  to  June, 
1976. 

• Addition  and  deletion  of  standard  B3500  systems,  and  the 
corresponding  rise  and  fall  in  storage  requirements,  may 
not  occur  in  accordance  with  the  schedule  presented  in  the 
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CAPS  report.  As  well,  the  storage  requirements  of  many  new 
systems  are  reflected  in  CAPS  as  "UNK." 

• The  projected  storage  requirement  baselines  and  computed 
VIMS  storage  requirements  of  the  sample  bases  may 
misrepresent  the  requirements  of  the  entire  population  of 
bases. 


ON-LINE  ACTIVITY  PROJECTION 
Summary 

The  simple  method  of  transaction  volume  projection  described 
below  involves  - 

1 ) Identification  of  transaction  types  employed  today  in  VIMS 
batch  processing  which  will  make  up  the  bulk  of  on-line 
VIMS  transaction  volumes. 

2)  Identification  of  relationships  between  vehicle  fleet  sizes 
and  daily  volumes  of  on-line  transaction  types. 

3)  Validation  of  these  relationships  against  observed  batch 
transaction  volume  data. 

ij)  Collection  and  analysis  of  sample  data  which  indicate  the 
work  order  processing  time  distributions  to  be  encountered 
at  Workload  Control.  (The  transaction  processing  workload 
at  Reports  and  Analysis  can  be  controlled  arbitrarily 
through  procedure,  since  it  is  not  closely  synchronized 
with  events  external  to  the  processing  system  such  as 
arrival  of  vehicles  to  be  serviced,  completion  of  work 
prders,  amendment  of  work  orders,  etc.) 

5)  Projection  of  daily  transaction  processing  at  Workload 
Control  distributed  across  a working  shift  at  several 
sample  bases  with  differing  fleet  sizes. 

High  Volume  Transaction  Types 

Inspection  of  the  monthly  batch  transaction  totals  at  17  bases 
(data  supplied  under  LGT  cover  letter  of  11  February  1975)  reveals 
that  only  four  transaction  types  comprise  the  bulk  of  the  workload 
reported  for  the  period.  Mean  relative  volumes  are  found  to  be  - 

MZ  H6%  (Fuel/Oil  Slips) 
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GZ  21$  (Labor  Time  Cards) 

WZ  15$  (Work  Order  Closes  with  Job  Detail) 

FZ  9$  (Work  Order  Open  without  Job  Detail) 

91$ 

It  is  assumed  that  current  FZ  and  WZ  transaction  volumes  may  be 
used  as  valid  indices  to  the  future  numbers  of  on-line,  work  order- 
based  transactions  (OPEN,  CLOSE,  AMEND,  etc.)  that  will  be 
encountered  at  Workload  Control.  Similarly,  MZ  and  GZ  volumes 
(fuel/oil  issues,  labor  time  cards)  are  taken  as  valid  predictors  of 
their  on-line  counterparts  to  be  processed  at  Reports  and  Analysis. 

Relationship  Between  Fleet  Size  and 
High  Volume  Transaction  Types 

For  ten  sample  bases,  monthly  totals  of  high  volume  transaction 
types  are  first  divided  by  21  to  produce  daily  totals  and  are  then 
divided  by  vehicle  fleet  size  to  generate  a daily  per-vehicle  index. 
For  each  transaction  type,  the  maximum  and  minimum  values  are 
discarded  and  the  mean  value  calculated  for  the  remaining  bases. 

The  per-vehicle  daily  transaction  coefficients  thus  yielded  are  - 

MZ  . 248 
GZ  .139 
WZ  .105 
FZ  .051 
.543 

As  an  example,  the  daily  volume  of  fuel/oil  issue  transactions 
for  any  particular  base  is  projected  as  roughly  equal  in  number  to 
one-quarter  of  the  base's  vehicle  fleet  size.  Since  these  factors 
were  derived  in  arbitrary  fashion  they  had  to  be  verified  against 
observed  data. 

Coefficient  Validation 


A sample  of  nine  bases  was  used  to  check  the  transaction 
projection  coefficients  using  the  following  method  - 

(21) (fleet  x .543)  - (observed  monthly  total  of  MZ+GZ+WZ+FZ)  = 
difference  between  predicted  and  actual  monthly  totals. 

On  a percentage  basis,  the  coefficients  yielded  predictions  that 
varied  from  five  percent  low  to  52  percent  high,  with  a mean  error 
of  20  percent  on  the  high  side.  This  appears  to  be  acceptable 
accuracy.  Figure  3 presents  a plot  of  predicted  daily  transaction 
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volumes  against  vehicle  fleet  size  as  developed  from  the 
coefficients  calculated  above. 


Time  Distribution  of  Predicted  Transaction  Volumes 
at  Workload  Control 


Unlike  that  of  R&A,  much  of  the  transaction  processing  load  at 
Workload  Control  is  keyed  to  external  factors  which  personnel 
operating  on-line  VIMS  cannot  easily  regulate.  In  order  to  identify 
a typical  pattern  of  workload  generation  over  time,  a sample  of  100 
work  orders  from  Hanscom  AFB's  files  was  analyzed  in  terms  of  time 
of  day  of  work  order  OPEN  and  CLOSE.  Separate  tallies  by  shift  hour 
for  both  OPEN  and  CLOSE  were  accumulated  while  ignoring  individual 
job  continuity  across  shift  boundaries.  Figures  4 and  5 show  for 
each  shift  hour  the  precentage  of  total  OPEN's  and  CLOSE'S 
processed.  Figure  6 shows  combined  totals  of  work  order  operations 
spread  across  the  shift. 

Sample  Projection 

Using  fleet  size  as  the  entering  argument,  daily  FZ  and  WZ 
volumes  were  developed  for  the  five  bases  in  Table  IV.  For  each 
base,  the  FZ  and  WZ  volumes  were  combined  and  spread  across  the 
daily  shift  in  accordance  with  the  Hanscom  workload  profile.  Note 
that  the  peak  hour  begins  at  0900,  and  that  for  any  base  the  number 
of  peak  hour  transactions  equals  fleet  size  x .022,  where  the  latter 
is  FZ  + WZ  coefficients  (.156)  x peak  hour  distribution  (.14).  Note 
also  that  no  time-flow  projections  have  been  made  for  R&A  since  the 
workload  there  can  probably  be  managed  via  arbitrary  procedure.  In 
any  case,  MZ  and  GZ  volumes  do  not  seem  to  threaten  terminal 
saturation.  (Combined  total  for  a 1200  vehicle  base  would  require 
processing  at  a rate  of  roughly  60  per  hour.) 

Caveats 


The  foregoing  analysis  and  conclusions  are  vulnerable  to  the 
usual  kinds  of  questions,  some  of  which,  hopefully,  have  been 
anticipated  below. 

• Only  a portion  of  the  total  number  of  on-line  transaction 
types  have  been  considered:  those  specifically  related  to 
the  FZ,  GZ,  MZ,  WZ  transactions  of  today's  batch  system. 
Transaction  volumes  projected  for  Workload  Control,  for 
example,  could  be  potentially  lower  than  the  actual  volumes 
(which  might  include  Materiel  Control  transactions  and 
other  types). 
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LEVEL 

LOAD 


Figure  4.  Percentage/Time  Distribution  a£  Warlt  Order  OPEH  Operations  — Sample 

of  10Q,.  Hanscom  AFB 
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LEVEL 

LOAD 


Figure  5.  Percentage/Time  Distribution  of  Work  Order  CLOSE  Operations  - Sample 

of  100,  Hanscom  AFB 
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and  CLOSE  Operations  - Sample  of  100 
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Table  IV 


Daily  Workload  Control  Transaction  Flows 
Projected  for  Five  Sample  Bases 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

VEHICLES 

BASES 

07  00 

0800 

0900 

1000 

1100 

1200 

1300 

1400 

1500 

1600 

1037 

Davis-Monthan 

18 

21 

23 

21 

18 

10 

18 

15 

8 

15 

1150 

McGuire 

20 

23 

25 

23 

20 

11 

20 

16 

9 

16 

1197 

Shaw 

21 

24 

~26 

" 24 

"21 

___ 

~2~ 

~ 17 

9 

17 

614 

Whiteman 

10 

12 

14 

12 

10 

6 

10 

9 

5 

9 

387 

Lowry 

— 

8 

g 

_____ 

_____ 

4 

7 

5 

3 

5 

Combined  work  order  OPEN's/CLOSE's  distributed  across  shift 
hours  in  accordance  with  percentage  distributions  established  by 
Hanscom  sample. 


• The  Hanscom  workload  profile  may  not  be  a valid  predicting 
tool  because  a)  Hanscom  operating  procedures  are  not 
representative  of  those  at  other  bases,  or  b)  the  Hanscom 
work  order  sample  reflects  some  temporary,  unusual 
condition.  As  with  any  workload  projection  method,  best 
practice  calls  for  use  of  workload  histories  from  the 
entire  population  of  potential  users,  covering  a year's 
time  period  to  permit  detection  of  seasonal  variations. 

• In  calculating  daily  workloads,  observed  monthly  totals 
were  assigned  uniformly  across  daily  boundaries  over  21 
work  days,  when  in  fact  peaks  and  valleys  in  the  workload 
are  probably  more  typical. 

Having  developed  a method  to  project  transaction  workload,  it 
remains  to  construct  the  rough  prototype  performance  estimators 
needed  to  test  for  terminal  input  saturation  given  the  workloads 
projected. 

Prototype  Performance 


A simplistic  performance  model  has  been  constructed  by 
arbitrarily  segmenting  the  on-line  system's  operating  time  into 
subunits  as  indicated  in  the  following  diagram: 


Terminal 

T R A 

, N S A C 1 

: i o n 

Terminal 

Trans- 

Idle 

Interchange  1 

-Busy 

Interchange  2 

>-Busy 

Idle 

Trans- 

action 

Time 

> 

Response 

Interval 

f > 

r 

1 

Response 
Interval 
t 3 

f 

Time 

action 

TIME 


That  is,  during  any  particular  operating  hour  there  may  be  both 
idle  and  transaction  time.  A transaction  is  composed  of  one  or  more 
interchanges,  the  basic  performance  accounting  unit  which  represents 
"busy"  time  at  an  input  terminal.  The  "response"  interval  lies 
within  a busy  period  as  shown  in  Figure  7 which  presents  the 
segments  of  activity  included  in  a single  interchange. 

The  intent  is  to  develop  a method  whereby  some  quantity  of 
elapsed  time  can  be  assigned  to  each  activity  based  on  a set  of 
variables  describing  system  communication  and  processing 
characteristics.  These  variables  are  number  of  terminals  per 
communication  line,  line  data  rate,  printer  speed,  average  message 
length,  disk  access  time,  coincident  disk  demand  (multi-programming 
factor),  processing  priority  assigned  to  on-line  VIMS,  and  a human 
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ACTIVITY  TYPE 

(D 


(2) 

(3) 

(4) 
(2) 

(3) 

(1) 


User  (external)  Action 




Line  Acquisition  (IN) 
Transmission  (IN) 
Process  IN/OUT 
Line  Acquisition  (OUT) 
**  4 


Terminal 

Awaiting 

Response 


Transmission  (OUT) 

User  (external)  Action 

< 


Te rminal 
BUSY 


* - User  roadblocked,  awaiting  response 
**  - First  character  of  response  arrives  at  terminal 


Figure  7.  Interchange  Activities 


activity  factor.  Each  activity  is  described  below  keyed  to  its 
associated  number  in  the  figure. 

(1)  An  external  activity  might  be  human  in  character  (document 
analysis,  a keying  operation,  conversation,  or  simple 
inattention),  or  it  might  be  a printing  operation.  Print 
rate  is  a performance  variable  and  print  duration  can  be 
calculated  as  a function  of  output  length  in  characters. 

For  timing  purposes,  it  is  assumed  that  the  terminal's 
memory  is  used  to  drive  the  printer,  and  that  terminal 
operation  is  roadblocked  during  the  print  process.  Timing 
of  human  operations  is  based  on  observations  of  the  model 
on-line  VIMS  system  in  action. 

(2)  Presuming  the  possibility  of  a multi-drop  communications 
configuration,  some  time  would  be  expended  in  waiting  to 
use  a busy  line  (waiting  for  a poll  message  from  the 
processor).  This  quantity  is  calculated  as  the  product  of 
average  line  time  in  or  out  (see  below)  and  half  the  number 
of  terminals  on  the  line,  excluding  the  "object"  terminal 
(the  terminal  for  which  performance  calulations  are  to  be 
made) . 

(3)  Transmission  (line)  time  is  the  product  of  average  message 
length  in  or  out  (in  characters)  and  transmission  code 
length  in  bits  divided  by  the  line  data  rate  in  bits  per 
second.  Code  length  is  assumed  to  be  10  bits  per 
character,  eight  data  bits  and  start/stop  bits. 

(4)  The  process  in/out  activity  incurs  a cost  in  time  as  the 
object  terminal's  input  message  waits  in  an  incoming  line 
queue  of  a length  equal  to  half  the  terminals  on  the  line 
less  the  object  terminal.  Input  messages  are  cleared  from 
the  queue  at  a rate  of  one  per  23  disk  I/O  access  times  (in 
milliseconds).  The  figure  of  23  disk  I/O's  per  interchange 
is  considered  conservatively  high:  according  to  SADPR-85, 
several  current  B3500  on-line  systems  require  a mean  of  23 
I/O's  per  transaction.  Added  to  the  input  queue  time  is 
the  product  of  on-line  VIMS's  processing  priority,  the 
number  of  systems  concurrently  contending  for  I/O 
resources,  and  the  time  incurred  by  23  I/O's  per 
transaction  in  the  queue.  This  quantity  is  disk  I/O  queue 
wait  time.  Added  to  the  total  is  time  required  for  the  23 
I/O's  for  the  object  terminal's  interchange.  It  is  assumed 
that  all  systems  contend  for  use  of  a single  disk 
channel/controller . 
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The  following  notation  is  used  to  identify  the  variables 
introduced  earlier: 

Ut  - user  activity,  pre-response  (sec's) 

U2  - user  activity,  post-response  (sec's) 

T - terminals  per  multi-drop  line 
L - line  data  rate  (bits  per  second) 

P - print  speed  (characters  per  second) 

Ai  - avg.  input  (to  processor)  message  length  (characters) 

A 2 - avg.  output  message  length 

A 3 - avg.  printer  output  length 

D - disk  access  time  (milliseconds) 

C - coincident  disk  demand  (jobs  active) 

V - VIMS's  processing  priority  (1  = equal  other  jobs) 

Where  B = terminal  busy  time  in  seconds  and  R = response 
interval  in  seconds,  the  following  relationships  are  established 
(The  number  prefixing  each  term  of  the  equation  refers  to  the 
textual  explanation  presented  above.) 

B = 


(1) 

Ui  + 

(2) 

(10Ai)(T-1)  + 

L 2 

(3) 

lOAi  + 

L 

(4) 

(T-1H23D)  + 2 3 VCD  + 23D 
2 

1000 

(2) 

(10A2)(T-1)  + 

L 2 
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(3) 

10A2  + 

L 

(1) 

U2  and, 

if  printing,  A3.. 

P 

R=B-(Ui 

+ 10A2  + Uz  + A 3)^ 

L P for  any  particular 

interchange. 

The  effect  of  changes  in  the  processing  environment  on  busy  and 
response  times  can  be  assessed  by  introducing  changes  in  the 
variables  used  in  the  above  calculation.  The  test  for  terminal 
saturation  during  a peak  transaction  hour  is  found  by  the  following 
calculation:  3600  seconds  - 

[(interchanges  per  transaction)  x (interchange  cost  in  seconds)  x 
(transactions  per  peak  hour)] 

If  the  result  is  zero  or  negative,  then  terminal  saturation  is 
projected.  Once  again,  it  is  the  Workload  Control  terminal  that  is 
of  interest  here,  since  the  arrival  timing  of  its  transaction 
volumes  is  only  minimally  controllable  by  the  system  user. 

Tables  V and  VI  show  the  results  of  some  calculations  made  at 
the  transaction  level.  Assumptions  implicit  in  these  calculations 
are 

• Workload  Control  will  primarily  process  work  order  OPENs, 
CLOSES  and  AMENDS.  This  presumes  use  of  a terminal  at 
Materiel  Control  to  service  parts  and  COPARS  transactions 
at  larger  bases,  and  a terminal  at  R&A  for  oil/gas 
transactions,  time  cards,  and  analytical  work. 

• The  most  costly  Workload  Control  transaction,  the  work 
order  OPEN,  requires  13  interchanges  and  involves  two  work 
order  print  operations.  This  estimate  is  made  based  on 
current  workings  of  on-line  VIMS  model  software,  and 
implies  error-free  transactions  involving  only  single  page 
presentations  of  potentially  multi-page  formats. 

Table  V shows  the  values  of  the  variables  used  to  reflect 
characteristics  of  the  on-line  VIMS  model's  processing  environment 
together  with  projected  minutes  per  transaction  (verified  against 
actual  model  performance),  and  projected  throughput  in  transactions 
per  hour.  These  results  are  generated  by  a kind  of  "best  case" 
processing  environment:  dedicated  minicomputer,  reasonably  high  line 
speed,  single-drop  communications,  etc.  Table  VI  shows  how 
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Table  V 


Variables  for  On-Line  VIMS  Model 


In  Quantity  - Units 

01>2  Human  Action  - 

Seconds 

T Terminals  Per  Line 


L Linespeed  - BPS 

P Print  rate  - CPS 

D Disk  Access  Time  - 

MILS 

Aj  Avg.  Input  Message 

- Chars. 

A 2 Avg.  Output  Message 

- Chars. 

A 3 Avg.  Printer  Output 

- Chars. 

C Coincident  Disk 

Demand  (Beyond  VIMS) 

V VIMS  Priority 


Origin  Value 

Observations  6/6 

Model's  Eguipment 
Configuration  1 

" 2400 

" 475 

" 24 

Model's  Current  Soft-  60 

ware  Configuration 

'•  250 


'»  2000 
" 0 

•i  i 


Calculation  yields  13.84  secs/interchange  + 4.21  secs/print  = 
3.14  minutes/transaction  = 19  transactions/hour  (Results  validated 
by  observation)  . 


Table  VI 


Selected  Variable  Combinations 


Case 

Key  Variable 

Elapsed  Time 
Per  Transaction 
(Min's) 

Throughput: 
Projected 
Transactions 
Per  Hour 

Response  Time  Per 
Interchange  (sec's) 

1 

T=3,  L=  1 2 0 0 r 
P=1 13,  C=  2 , 
V=1,  D=  23 

4.77 

12 

5 

2 

1 1 

II  II 
(J  > 

1 I 

5.00 

12 

6 

3 

C=  4 
V=2 

5.45 

11 

8 

4 

1 

1 

1 

1 

< Ol 
II  II 1 
p -PI 

1 

! 

1 

i i 

6.37 

9 

13 

5 

D=4 0 ♦ case  1 

5.11 

11 

7 

6 

D=40  ♦ case  2 

5.50 

10 

9 

7 

D=40  ♦ case  3 

6.30 

9 

12 

8 

D=40  + case  4 

7.90 

7 

20 

projected  on-line  VIMS  performance  varies  with  some  changes  in  its 
operating  environment. 

For  cases  1-8,  the  variables  were  established  to  simulate  a 
multi-programming  environment  (as  opposed  to  a dedicated  computer), 
with  differing  numbers  of  systems  contending  for  disk  access  and 
with  VIMS  given  a progressively  lower  priority.  Communications 
variables  were  configured  to  simulate  a 1200  bps  line  shared  by 
three  terminals.  (AFDSDC/SYO's  "Terminal  Configuration  Guide"  urges 
that  1200bps  lines  be  used  initially  with  all  CRT's  installed  at 
base  level,  and  presents  several  configuration  options  incorporating 
shared  lines.)  As  well,  a print  speed  variable  of  113  cps  was  used 
to  simulate  the  85  1pm  performance  of  the  Burroughs  B9249-1  printer 
projected  for  use  with  the  TD822  terminal.  (The  TD822  will  be 
installed  with  MMICS  increment  2 and  MACARMS) . 

In  cases  1-4,  disk  access  time  was  set  to  23  milliseconds,  and 
for  cases  5-8  it  was  set  to  40  milliseconds.  CAPS  Report  Number 
Nine  indicates  that  a base  DPI  may  be  equipped  with  either  or  both 
of  these  classes  of  disk  storage. 

The  last  column  of  Table  VI  presents  response  time  per 
interchange  in  seconds  computed  for  each  of  the  processing 
environments  outlined  above.  Response  time  yielded  by  the 
calculation  when  variables  are  set  to  simulate  the  on-line  VIMS 
model  is  0.8  seconds  which  corresponds  closely  with  the  model's 
observed  performance. 

Figure  8 is  a terminal  sizing  graph  which,  when  used  with  output 
from  the  performance  model,  yields  an  estimate  of  the  number  of 
terminals  required  to  OPEN,  CLOSE,  and  AMEND  work  orders  at  bases 
with  various  fleet  sizes.  For  example,  a 500  vehicle  base  must  be 
able  to  complete  a transaction  in  something  under  five  and  a half 
minutes  if  a single  Workload  Control  terminal  is  to  suffice.  Some 
words  of  caution: 

• The  graph  assumes  that  all  peak  hour  transaction  loads  must 

be  processed  during  that  hour,  although  some  small  residual 
loads  from  the  peak  hour  could  be  absorbed  during 
succeeding  hours.  Note:  The  Hanscom  AFB  workload  profile 

was  used  in  developing  the  graph.  This  profile  should  be 
validated  against  those  of  several  other  installations 
before  any  serious  sizing  decisions  are  made. 

• The  number  of  interchanges  used  to  develop  transaction 
timing  is  keyed  to  the  current  software  configuration  of 
the  on-line  VIMS  model.  The  actual  number  of  interchanges 
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Workload  Control 
Terminals 
Required 


Minutes  per  VEHICLE  FLEET  SIZE 

Transaction 

(from  Performance  Model) 

Figure  8.  Terminal  Sizing  Graph 


per  work  order  transaction  will  remain  unknown  until  design 
of  the  prototype  is  complete  and,  in  fact,  the  design  may 
be  keyed  to  the  minimization  of  interchanges  if  system 
performance  estimates  appear  marginal. 

# It's  possible  that  local  conditions  may  dictate  use  of  more 
Workload  Control  terminals  than  the  numbers  suggested  by 
the  sizing  graph.  This  would  be  the  case,  for  example,  at 
those  bases  operating  multiple  Workload  Control  processes 
in  parallel  at  widely  separated  locations.  These  same 
kinds  of  conditions  could  require  use  of  multiple  terminals 
to  perform  the  Materiel  Control  or  Reports  and  Analysis 
functions  at  high  activity  bases. 
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SECTION  V 


PROTOTYPE  DEVELOPMENT  PLANNING 

This  section  identifies  development  tasks,  schedules,  and  costs 
associated  with  the  development  alternatives. 


TASKS  AND  SCHEDULES 

Identified  below  are  the  significant  prototype  development  tasks 
associated  with  each  implementation  option.  Tasks  have  been 
assigned  to  development  program  years  without  special  knowledge  of 
AFDSDC's  capabilities  in  various  technical  areas  or  the  planned 
interactions  with  other  development  programs  (STALOG,  BASE-TOP, 
etc.).  Obviously,  each  task  identified  below  may  be  fragmented  into 
any  number  of  subtasks.  The  projected  schedules  are  considered 
tight,  and  can  be  met  only  through  very  careful  planning, 
availability  of  competent  and  productive  software  personnel,  and 
availability  of  adequate  computer  time  for  system  development.  For 
scheduling  purposes,  OLVDED  is  considered  as  a planned  extension  of 
OLVHYB  for  program  years  4 and  5. 


0LV3500:  B3500-0nlv  Implementation 
Year  1 Tasks 


1)  Plan  project  (equipment  acquisition,  software  development, 
file  conversion,  etc.),  assign  and  brief  personnel. 

2)  Document  the  current  batch  VIMS  system  to  a degree 
permitting  identification  of  individual  functional  modules 
and  their  processing  characteristics.  Much  of  this  task 
must  be  completed  prior  to  completion  of  1)  above. 

3)  Write  an  external  functional  description  of  OLVP  (including 
operator  procedures)  and  a preliminary  test  plan. 

4)  Analyze  AFOLDS  in  its  current  and  projected  forms  to 
determine  its  possible  assistance  in  a data  management 
role. 

5)  Perform  communications  systems  analysis  and  prepare 
terminal  and  line  specifications.  (See  AFDSDC/SYO's 
"Terminal  Configuration  Guide,”  January  1975). 
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6)  Procure  and  accept  terminals. 

7)  Based  on  Tasks  1)  - 5),  design  new  on-line  software,  and 
changes  to  the  batch  run.  Review  and  document  in 
accordance  with  established  procedures. 

Year  2 Tasks 


1)  Write,  check  out,  and  document  software: 

Modified  batch  run 

On-line  support 

File  conversion/installation  utilities. 

2)  Conduct  integration  and  first  level  test  of  OLVP  equipment 
and  software. 

3)  Write  prototype  installation  and  conversion  Plan. 

4)  Design  and  implement  user  training  course,  and  conduct  user 
training. 

5)  Conduct  second  level  (field)  testing  and  system  cutover. 

6)  Write  transition  plan  in  preparation  for  system  conversion 
to  new  base-level  ADPE  environment. 

OLVHYB:  Hybrid  FEP-B3500  Implementation 

Year  1 Tasks 


Same  as  OLV3500 
Less: 

• AFOLDS  Analysis 
Plus: 

• FEP  Procurement  and  Acceptance  Testing 

• Programmer  Training  (equipment,  operating  system,  etc.) 

Year  2 Tasks 

1)  Continue  design  effort  begun  during  year  1. 

2)  Write,  check  out,  and  document  software: 

Modified  batch  run 
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On-line  Support  (B3500) 

On-line  Support  (FEP) 

File  eonversion/installation  utilities. 

3)  Conduct  integration  and  first  level  test  of  OLVP  equipment 
and  software. 

Year  3 Tasks 

1 ) Write  prototype  installation  and  conversion  Plan. 

2)  Design  and  implement  user  training  course,  and  conduct  user 
training. 

3)  Conduct  second  level  (field)  testing  and  system  cutover 
(hybrid  implementation). 

4)  Plan  transition  to  OLVDED  based  on  observation  of  hybrid 
system. 

OLVDED:  Dedicated  VIMS  Minicomputer  Implementation  (Scheduled  as 
OLVHYB  Extension) 


Year  4 Tasks 


1 ) Design  and  implement  FEP-only  master  file  processing  and 
file  conversion  software. 

2)  Conduct  integration  and  first  level  test  of  FEP-only 
configuration. 

3)  Write  installation  and  conversion  plan. 

Year  5 Tasks 


1)  Conduct  second  level  (field)  testing  and  system  cutover 
Summary 

To  summarize  the  schedules  defined  above: 

• OLV3500  development  appears  to  fit  within  a two  year  time 
frame. 

• OLVHYB  implementation  spills  into  a third  year  because  of 
the  potentially  more  complex  procurement  problem  associated 
with  FEP  acquisition,  and  the  need  to  train  and  familiarize 
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personnel  with  a new  computer.  An  additional  year  is 
required  for  observation  of  the  system  in  its  hybrid 
implementation,  and  for  design  and  implementation  of 
additional  FEP  software. 

The  OLVHYB  schedule  could  be  compressed  should  the  FEP 
acquisition  process  be  shortened,  or  if  FEP  operating  system 
software  can  provide  extensive  transaction  routing/queuing  services, 
or  if  the  FEP  can  be  provided  with  a proven  centralized/generalized 
data  management  system. 

Keyed  to  calendar  years,  the  schedules  implied  above  are 
equivalent  to: 


QLV3500 

Start  development:  July,  1975 
On-line:  July,  1977 

OLVHYB/DED 

Start  development:  July,  1975 
OLVHYB  on-line:  January,  1978 
OLVDED  on-line:  July,  1979 


MANPOWER  REQUIREMENTS 

The  tasks  and  schedules  specified  above  imply  the  use  of  various 
numbers  of  personnel  within  several  labor  categories.  For 
convenience,  these  categories  have  been  grouped  into  teams  to  deal 
with  project  management,  software  development,  equipment  and 
services  procurement,  system  test,  training  and  installation,  and 
computing  facilities.  It  is  recognized  that  AFDSDC's  organizational 
conventions  probably  do  not  coincide  with  the  project  organization 
proposed  here.  Whatever  formal  structures  are  employed,  however, 
the  tasks  to  be  accomplished  remain  the  same. 

Table  VII  defines  the  man-loading  and  labor  categories 
associated  with  each  of  the  development  options. 

Table  VIII  indicates  team  phasing  and  man-loading  totals  across 
development  program  years. 


* 
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Table  VII 


Development  Manpower 


SY  STEM  _ DEV  _ELO  PH  EN  T_TE  A ft  S OLIi  5M„0LVHTB^DED 

Project  Management 
Managers 
Clerical 


Software  Development 

Software  Supervisors  2 
Functional  Consultants/Liaison  2 
Programmers  5 
Clerical  2 


Eguipment/Ser vices  Procurement 

Technicians 
Clerical 

System  Testr  Training,  and  Installation 


Supervisors  1 
Training  Specialists  2 
Programmers  2 
Clerical  2 


Computing  Facilities 

Supervisors 
Computer  Operators 
Equipment  Maintenance 

NOTE:  Actual  numbers  of  individuals  required  should  be 

smaller  than  indicated  totals  since  multiple  roles 
may  be  assumed  by  a single  individual  during  suc- 
ceeding phases  of  the  project. 


2 

1 


2 2 

1 1 


TOTAL  24  38 

NOTE:  More  STTSI  teams  would  be  needed  should 

plans  call  for  parallel  installation  of 
the  prototype  at  multiple  bases. 
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Table  VIII 


Manpower  by  Development  Year 


DEVELOPMENT  YEAR 

1 

2 

3 

4 

5 

Project  Management 

3 

3 

Software  Development 

11 

11 

Equipment/Services  Procurement 

3 

System  Test,  Training,  and  Installation 

7 

Computing  Facilities 

TOTALS  OLV3500 

17 

21 

Project  Management 

3 

3 

3 

3 

3 

Software  Development 

16 

16 

16 

16 

Equipment/Services  Procurement 

6 

6 

System  Test,  Training,  and  Installation 

8 

8 

Computing  Facilities 

5 

5 

5 

5 

TOTALS  OLVHYB 

25 

30 

32 

24 

16 

OLVDED 


EQUIPMENT  REQUIREMENTS 

In  addition  to  the  B3500,  an  0LV3500  implementation  would 
require  two  basic  terminals,  while  the  OLVHYB  and  OLVDED 
configurations  would  require  addition  of  an  FEP  minicomputer: 

Basic  Terminal  (CRT  Keyboard  and  Printer) 

Data  Rate:  1200-2400  bps 

Screen  Capacity:  2000  chars  (with  full  screen  buffer  and 

protected  fields  feature) 

Print  Rate:  165-200  chars/sec 

FEP  Minicomputer 

Main  Memory:  32-64K  bytes 

Secondary  Memory:  20  megabytes,  removable  disk  storage 

Standard  Peripherals:  Console,  Tape  and  Card  1/0,  Line  Printer 


COSTS 


Equipment  cost  estimates  were  derived  from  the  Auerbach  Reports, 
vendor  literature,  and  the  SADPR-85  final  report  (Support  of  Air 
Force  Automatic  Data  Processing  Requirements  through  the  1980 's, 

Vol.  3,  Technology:  Electronics  Systems  Division,  Air  Force  Systems 
Command,  June  1974), 


The  costs  shown  below  reflect  a predicted  decline:  those  quoted 
in  the  total  program  cost  summary  (Table  IX)  are  the  maximum 
estimates  for  1975, 


Basic  Terminal 
FEP  Minicomputer 


Purchase  Cost 
1975 

$3,000  - $6,000 
$65,000  - $100,000 


Purchase  Cost 

mi 

$2,000  - $5,000 
$50,000  - $75,000 


Table  IX  summarizes  total  program  costs  by  option  by  development 
year.  Personnel  costs  are  developed  from  the  man-loading  totals 
presented  in  Table  VIII  and  a man-year  cost  factor  of  $10,400 
(STAL0G  precedent).  Costs  of  a conditional  B3500  disk  storage 
upgrade  described  earlier  are  not  included  in  these  totals. 
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Table  IX 


Total  Prototype  Development  Program  Costs 


Develop- 
ment Year 

Equip. 

OLV3500 

Pers. 

Tot. 

Equip. 

OLVHYB 

Pers. 

Tot. 

Equip. 

OLVDED* 

Pers. 

Tot. 

1 

$12,000 

$176,800 

$188,800 

$112,000 

$260,000 

$372,000 

- 

- 

- 

2 

- 

218,400 

218,400 

- 

312, 000 

312,000 

- 

- 

- 

3 

- 

- 

- 

- 

332,800 

332,800 

- 

- 

- 

4 

- 

- 

- 

- 

- 

- 

- 

$249, 600 

$249,600 

5 

- 

- 

- 

- 

- 

- 

- 

$166, 400 

$166,400 

TOTAL 

$12,000 

$395,200 

$407,200 

$112,000 

$904, 800 

$1,016,800 

*- 

$416,000 

$416,000 

♦ OLVDED  would  utilize  equipment  procured  for  OLVHYB. 
Personnel  costs  are  in  addition  to  those  for  OLVHYB. 


APPENDIX  I 


ON-LINE  VIMS  WORKLOAD  PROJECTION 


This  Appendix  describes  in  detail  the  methods  used  to  forecast 
on-line  VIMS  prototype  workloads  to  be  processed  by  the  B3500 
computer.  Projections  made  here  should  also  be  valid  for  computers 
incorporating  processors  and  disk  I/O  configurations  similar  to 
those  of  the  B3500. 

Figure  9 provides  a guide  to  the  workload  estimation  process.  Of 
the  variety  of  possible  measures,  direct  time  hours  (DTH)  was 
selected  as  most  convenient  for  use  in  VIMS  workload  projection.  A 
B3500  operational  use  hour  (OUH)  is  composed  of  DTH,  that  fraction 
of  time  during  which  work  is  being  done  by  or  for  specific  data 
systems,  and  prorated  time  hours  (PTH),  that  remaining  fraction 
which  is  overhead  time  not  chargeable  to  specific  systems,  yet 
assigned  to  all  on  a prorated  basis  as  a function  of  the  job  mix.  A 
data  system's  OUH  demand  per  some  unit  time  at  a specific  DPI  can  be 
calculated  by  estimating  DTH,  as  is  shown  below,  and  inflating  this 
value  by  some  measure  of  PTH  based  on  the  DPI's  history  of  "percent 
direct,"  a statistic  available  through  B3500  accounting  routines. 

It  is  necessary  to  convert  DTH  to  OUH  in  this  fashion  since  DPI 
saturation  is  calculated  on  an  OUH  basis. 

The  objective,  then,  was  to  develop  a method  to  calculate 
projected  on-line  VIMS  DTH  using  some  independent  variable,  add  PTH, 
and  test  for  OUH  saturation.  Vehicle  fleet  size  seemed  to  be  a 
sensible  independent  variable  since  on-line  VIMS  will  process  many 
transactions  corresponding  on  a one-to-one  basis  with  specific 
vehicles,  each  transaction  incurring  a cost  in  DTH.  As  requested, 
AFDSDC/SY  provided  several  regression  analyses  (LGT  cover  letter  18 
October  1974)  indicating  the  relationships  between  vehicle  fleet 
sizes  and  DTH,  PTH,  cards  read/punched,  disk  I/O's  and  other 
potential  workload  measures.  The  analyses  were  made  using  B3500 
accounting  data  gathered  at  24  bases  during  the  months  of  June  and 
July,  1974.  These  provided  two  linear  equations  showing  the 
relationship  between  fleet  size  and  monthly  DTH  for  the  current 
batch  mode  VIMS.  The  equations  are  of  the  form 

Y = a + bX 

where 

Y is  the  dependent  variable,  monthly  DTH, 
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Figure  9.  Overview:  OLVP  Workload  Analysis 
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X is  the  independent  variable,  vehicle  fleet  size, 

a is  the  Y value  at  the  point  where  the  regression  line 
described  by  the  equation  intercepts  the  Y axis,  and 

b is  slope  of  the  regression  line,  the  value  by  which  Y 
increases  per  unit  increase  in  X. 

Figure  9 indicates  that  the  two  equations  (one  based  on  June, 
1974  data,  the  other  based  on  July  data)  were  incorporated  directly 
into  a list  which  later  grew  in  size  to  five  entries.  Because  these 
two  equations  were  derived  from  observations  of  batch  processing 
rather  than  on-line  processing,  and  because  the  July  data  was 
suspect  (for  reasons  given  below),  it  was  determined  that  a second 
set  of  equations  was  needed  incorporating  an  on-line,  transaction 
processing  orientation. 

The  scheme  chosen  to  develop  the  second  set  was  based  on  the 
apparent  close  relationship  between  DTH  and  physical  disk  I/O's 
performed  per  unit  time  as  demonstrated  by  current  VIMS  batch 
processing  on  the  B3500.  (A  regression  analysis  yielded  a 
correlation  coefficient  of  .95  using  monthly  DTH  and  disk  I/O  data 
from  23  sample  bases.)  In  brief,  the  objective  was  to  assign  a 
number  of  disk  I/O's  required  by  each  on-line  VIMS  transaction  type. 
convert  these  to  a corresponding  DTH  value  using  several  different 
methods,  and  by  means  of  subsequent  regression  analyses  relate 
vehicle  fleet  size  to  the  DTH  values  thus  developed.  These  could 
then  be  used  as  a basis  from  which  to  project  monthly  and  daily 
workloads  generated  by  fleets  of  various  sizes. 

The  point  of  departure  was  a tabulation  of  monthly  batch  VIMS 
transaction  volumes  gathered  from  nine  sample  bases  whose  fleet 
sizes  ranged  from  387  to  1197  vehicles  (both  registered  and  non- 
registered).  See  Table  X.  The  suspected  correspondence  between 
fleet  sizes  and  total  batch  transaction  volumes  was  confirmed 
through  a regression  analysis  which  yielded  a correlation 
coefficient  of  .95.  (Transaction  totals  per  base  included  only 
those  applicable  to  on-line  VIMS:  FZ,  WZ,  SZ,  NZ,  PZ,  EZ,  QZ,  MZ, 
and  GZ) 


It  was  then  necessary  to  assign  numbers  of  disk  I/O's  to  each 
on-line  transaction  type.  This  was  done  in  an  arbitrary  fashion 
using  a single  set  of  assignment  ground  rules.  Each  transaction  type 
was  analyzed  to  identify  the  data  file  read/write  operations  it 
required;  it  was  assumed  that  access  to  each  file  would  require  use 
of  three-level  indices  (two  of  these  disk-resident);  it  was  assumed 
that  each  message  generated  by  a transaction  (number  arbitrarily 
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assigned)  would  be  logged  on  disk  and  subsequently  logged  off  to 
magnetic  tape.  The  I/O's  per  the  20  odd  on-line  transaction  types 
(the  sum  of  data  file  reads/writes,  index  fetches,  and  message 
logging)  ranged  from  1 1 to  27  with  a mean  of  19.  (The  mean  I/O  per 
transaction  estimate  of  19  seems  reasonable  when  one  considers  that 
23  is  the  mean  number  of  I/O's  per  transaction  associated  with  the 
current  B3500  on-line  systems  serving  the  personnel,  accounting  and 
finance,  and  civil  engineering  functional  areas.)  The  following 
procedure  was  used  to  derive  total  monthly  I/O  tallies  for  each  of 
the  nine  sample  bases. 

For  each  base,  the  10  most  frequently  occurring  on-line 
transaction  types,  accounting  for  90  percent  of  total  volume,  were 
summed  and  augmented  by  10  percent  of  the  sum  to  account  for 
infrequently  occurring  types.  This  sum  was  multiplied  by  19  (mean 
number  of  I/O's  per  transaction)  and  this  I/O  total  was  arbitrarily 
inflated  by  50/S  to  allow  for  growth  and  contingencies  (disk  activity 
of  the  B3500  operating  system  in  support  of  VIMS,  periodic 
checkpointing  operations  in  support  of  a system  restart  capability, 
etc.).  See  Table  X. 

These  monthly  I/O  volumes  for  the  nine  sample  bases  were  the 
common  departure  point  for  three  separate  I/0-to-DTH  conversion 
procedures  proceeding  from  three  different  data  sources:  a disk  I/O 
conversion  coefficient  incorporated  in  the  Workload  Analysis  Model 
(WAM-Operations  Research  Division,  Directorate  of  Systems 
Technology,  AFDSDC),  a coefficient  derived  from  observation  of  batch 
VIMS  operations,  and  a coefficient  derived  from  observation  of 
current  on-line  systems. 

Section  III  of  WAM  Report  #2  (OR  Project  All-72,  November  1972, 
AFDSDC/SYO)  presents  several  equations  used  by  the  model  to  forecast 
direct  time  from  a number  of  combinations  of  I/O  operations  (lines 
printed,  cards  punched,  etc.).  One  of  these  equates  one  hour  of 
direct  time  to  71,200  physical  disk  I/O's,  based  on  one  month's 
worth  of  DTH  and  I/O's  observed  at  25  B-level  DPI's. 

The  batch  VIMS  conversion  factor  was  derived  from  a regression 
analysis  incorporating  data  from  23  bases  gathered  during  June  of 
1974.  The  on-line  system  conversion  factor  was  produced  via 
regression  analysis  using  on-line  activity  data  gathered  during 
September  of  1974  at  the  same  bases. 

The  conversion  algorithms  developed  from  the  sources  identified 
above  are: 

• (WAM  Constant) 
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Table  X 

Fleet  Sizes  and  Monthly  Transaction  Volumes 

For  Nine  Sample  Bases  (From  STALOG's  Source  Data 

•'Base  Collection  Files"  Processes 
B34-35) 


Proj  ected 


Base 

Fleet 

Size* 

Monthly 

Transactions** 

Monthly 
Disk  I/O 

Davis-Monthan 

1037 

13,230 

414.7 

McGuire 

1150 

13, 350 

418.  5 

Shaw 

1197 

11,000 

344.  8 

White  man 

614 

6,800 

213.  2 

Grissom 

564 

5,200 

163.0 

Randolph 

645 

6,  475 

202.9 

Castle 

434 

4,000 

125.  4 

Lowry 

387 

4,  300 

134.  8 

Hanscom 

475 

3,600 

112.  8 

♦NOTE:  Includes  both  registered/non- registered  vehicles. 

♦♦NOTE:  Transaction  volumes  reflect  only  those  types  applicable 
to  on-line  VIMS:  FB,  RB,  SB,  NB,  P«,  E£ 

QB,  MB,  GB. 

♦♦♦NOTE:  Expressed  in  thousands,  where 


Total  I/O's  = 

(110%  transactions)  (28.5  I/O's) 


Y = 0 + .014045X 

• (Batch  VIMS) 

Y = -.02709  + .0065X 

i 

• (Current  On-line  Systems) 

Y = -.88219  + .01 1 37X 

(Where  Y is  monthly  DTH,  and  X is  monthly  disk  I/O's  expressed 
in  thousands.) 

Each  of  the  three  sets  of  nine  DTH  data  points  was  associated 
with  fleet  size  data  points  for  each  of  the  .nine  bases  to  produce 
regression  equations  (3),  (4),  and  (5)  of  the  following  list.  As 
mentioned  above,  equations  (1)  and  (2)  were  produced  by  AFDSDC/SYO's 
regression  analyses  based  on  June  and  July  1974  observations. 

(1)  Y = .63327  + .00338X 

r 2 = .45  2Syx  = 2.09614 

VIMS  Batch,  24  Bases,  June  1974 

(2)  Y = .00574  + .00720X 

r2  = .72  2Syx  = 2.55468  ' 

VIMS  Batch,  24  Bases,  July  1975 

(3)  Y = -.43691  + .00512X  r 

rz  = .91  2Syx  = 1.10790 

Projected  on-line  workload,  1/0-to-direct  time  conversion 
via  WAM  constant 

(4)  Y = -.22554  + .00241X 
rz  = .91  2Syx  = .51402 

Projected  on-line  workload,  I/O-to-direct  time  conversion 
via  batch  VIMS  coefficient 

(5)  Y = -1.05125  + .00409X 
r2  = .85  2Syx  = 1.17722 

1/0-to-direct  time  conversion  via  on-line  systems 
coefficient 

Figure  10  shows  a plot  of  the  regression  lines  represented  by 
the  five  equations.  The  lines  appear  to  cluster  together  in  an 
encouraging  way.  For  a fleet  of  600  vehicles,  for  example,  the 
maximum  and  minimum  DTH  values  as  projected  by  equations  (2)  and  (4) 
are  4.25  and  1.25  hours  respectively.  Given  a mean  processing  load 
(24  base  sample)  of  171.47  DTH  per  month,  the  difference  between 
these  values  becomes  insignificant. 
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There  are  grounds  for  disqualification  of  equation  (2),  based  on 
irregularities  in  the  July  1974  data  from  which  it  was  derived:  the 
July  data  includes  processing  for  the  April  - June  quarter,  a one- 
time effort  to  convert  management  codes  for  all  vehicles,  and  a one- 
time upload  of  the  CAFVIMS  data  base.  (See  AFDSDC/LGT  letter  of  18 
October  1974.)  Discarding  equation  (2),  the  picture  improves  nicely, 
given  the  small  dispersion  of  the  remaining  regression  lines, 
particularly  in  light  of  their  diverse  origins. 

Figure  11  shows  the  maximum  and  minimum  value  envelope  where  the 
dashed  lines  represent  two  times  the  standard  error  of  estimate  for 
equation  (1)  on  the  high  side  and  for  equation  (5)  on  the  low  side. 
(Given  a normal  distribution  of  points,  the  : 2Syx  bands  on  either 
side  of  a regression  line  designate  an  area  within  which  95  percent 
of  all  points  should  fall. ) The  extent  of  the  envelope  is  obviously 
exaggerated  since  scope  is  permitted  for  negative  DTH  for  fleet 
sizes  of  less  than  600. 

Table  XI  summarizes  the  impact  of  on-line  VIMS  processing  on  the 
workloads  of  20  sample  bases  projected,  via  the  CAPS  Report,  for 
June  of  1976.  The  CAPS  baseline  data  is  presented  first,  followed 
by  projected  on-line  VIMS  OUH.  A worst  case  monthly  DTH  value  was 
selected  for  each  fleet  size  from  along  equation  ( 1 ) 's  2Syx  parallel 
and  converted  to  monthly  OUH  by  use  of  a "percent  direct"  value  of 
18.8.  This  figure  represents  the  mean  direct  time  component  of  the 
OUH  totals  for  on-line  systems  observed  at  24  bases  during  the  month 
of  September  1974.  For  the  20  base  sample,  a mean  increase  in 
workload  of  six  percent  was  projected. 

The  negligible  workload  increase  attributable  to  VIMS  as  shown 
by  the  monthly  analysis  may  be  misleading  since  competition  for  on- 
line computer  resources  is  not  spread  uniformly  and  cooperatively 
across  a month  but  takes  place  instantaneously  and  randomly. 
Coincidence  of  demand  can  create  a momentary  saturation  whose 
externally  perceptible  symptom  would  be  an  increase  in  response  time 
of  on-line  systems.  There  is  no  instantaneous  resource  demand 
baseline  available  for  the  on-line  systems  operating  today  with 
which  on-line  VIMS  will  have  to  compete.  The  next  best  measure 
appears  to  be  a daily,  on-line  shift  baseline,  but  even  this  can  be 
misleading  since  workloads  must  be  distributed  uniformly  across 
daily  boundaries. 

Table  XII  presents  daily  analyses  derived  from  extreme  DTH 
values  (corresponding  to  fleet  sizes)  which  lie  along  the  2Syx 
parallels  of  equations  (1)  and  (5).  Projected  daily  on-line  VIMS 
OUH  were  calculated  by  inflating  monthly  DTH  by  the  18.8  "percent 
direct"  factor  and  dividing  by  the  number  of  on-line  days  in  the 
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Figure  11.  Projected  DTH : Max/Min  Envelope 


Table  XI 


Monthly  Impact  of  On-Line  VIMS 
Summary:  20  Sample  Bases 


Fleet  Size 

June  J976, 
Max  0 OH 
Workload 

Baseline  (CAPS  Nine) 
Projected  Percent 
Workload  Utilized 

VIMS  OUH 
Workload 

Percent 
Increa se 

Percent 
Utilized 
with  VIMS 

Max 

1197 

663 

612 

95 

39 

7 

99 

Min 

235 

601 

421 

65 

19 

4 

69 

Mean 

724 

641 

496 

77 

28 

6 

82 

Table  XII 


Daily  Impact  of  On-Line  VIMS 
Summary:  24  Sample  Bases 


Sampled 

On-Line 

Days 

Fleet 

Size 

Mean  Daily 

On-Line 

OUH 

Projected 
Daily  VIMS 
OUH 

Total 

Percent 

Increase 

Equation  (1)  - 

Maximum 

VIMS  OUH  Values 

Max 

27 

1191 

4.87 

1.88 

6.07 

52 

Min 

15 

235 

2.76 

.78 

4.03 

17 

Mean 

20 

600 

3.94 

1.  21 

5.15 

31 

Equation  (5)  - 

Minimum 

VIMS  OUH  Values 

Max 

27 

1191 

4.87 

.59 

4.92 

14 

Min 

15 

235 

2.76 

- 

- 

- 

Mean 

20 

600 

3.94 

.22 

3.94 

6 

NOTE:  Max/Min/Mean  values  are  summarized  from  the  24  base 
tabulation  on  a Column  basis.  The  figures 
shown  above  have  no  particular  relationship  on  a 
row  basis. 


reporting  period  for  each  base.  Results  indicate  a mean  OUH  demand 
increase  during  the  on-line  shift  of  from  15  minutes  to  an  hour  and 
15  minutes.  The  mean  percentages  of  increase  of  six  and  31  should 
not  be  interpreted  as  increases  in  on-line  system  response  time 
since  resource  demands,  and  therefore  instantaneous  saturation 
conditions,  could  occur  randomly. 


CONCLUSIONS 

To  the  extent  that  the  monthly  and  daily  resource  demand 
baselines  can  be  trusted  as  reasonably  accurate,  and  in  the  absence 
of  additional  high  activity  on-line  systems  in  the  future,  it 
appears  as  if  the  operation  of  an  on-line  VIMS  prototype  will  not 
dangerously  threaten  saturation  of  B3500  resources  during  the  on- 
line shift  except  at  those  DPI's  needing  upgrade  which  operate  today 
in  a condition  of  marginal  saturation. 

When  interpreting  the  results  of  the  prototype  on-line  VIMS 
workload  analysis,  one  must  recall  certain  features  in  the  method 
used: 

1.  As  with  any  correlation-based  forecast,  the  equations 
derived  represent  an  idealized  best  fit  of  a line  to  what 
may  actually  be  widely  dispersed  data  points.  In  any  case, 
valid  estimates  of  the  dependent  variable  (workload 
expressed  as  monthly  DTH)  can  be  made  only  when  employing 
values  of  the  independent  variable  (vehicle  fleet  size) 
which  lie  between  the  extremes  observed  when  constructing 
the  regression  line.  That  is,  the  equations  presented 
above  can  yield  valid  workload  estimates  only  for  the  cases 
where  fleet  size  lies  between  400  and  1200. 

2.  Although  a generous  sample  of  bases  (24)  was  available  for 
calculation  of  DTH  and  physical  disk  I/O  quantities,  only  a 
limited  sample  (9)  could  be  used  to  calculate  transaction 
oriented  data.  However,  the  sample  did  contain  a repre- 
sentative spread  of  fleet  sizes  and  demonstrated  excellent 
correlation  between  fleet  sizes  and  transaction  volumes, 
confirming  what  had  been  an  intuitive  assumption. 

3.  The  assignment  of  disk  I/O's  to  on-line  transactions  was 
arbitrary  and  represents  a best  guess  only  in  the  absence 
of  a preliminary  system  design.  By  the  same  token, 
arbitrary  assignment  is  consistent.  Note  also  that  a 50 
percent  expansion  factor  was  added  to  the  1/0  total  of  each 
sample  base. 
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4.  Use  of  a "percent  direct"  value  of  18.8  percent  for 
conversion  of  DTH  to  OUH  is  not  entirely  realistic  since 
the  value  actually  varies  from  base  to  base  and,  for  any 
one  base,  can  vary  over  time.  In  its  favor,  the  figure 
describes  observed  performance  of  on-line  systems  at  24 
bases  during  the  month  of  September,  1974. 

5.  The  monthly  and  daily  workload  baselines  and  VIMS 
projections  are  likewise  not  entirely  realistic  since  they 
were  of  necessity  spread  uniformly  across  units  of  time. 
Hopefully,  however,  any  errors  introduced  were  made  on  the 
high  side  since  care  was  taken  to  add  a 50  percent  I/O 
expansion  factor  and  to  develop  the  monthly  and  daily 
analyses  fhora  data  lying  along  the  extreme  boundary  of  the 
workload  envelope. 

Installation  of  high  activity  on-line  systems  in  the  future 
will  invalidate  the  workload  baseline  assumptions  used 
above  and  thereby  invalidate  judgements  made  as  to  on-line 
VIMS'  potential  for  B3500  saturation.  (The  daily  analysis 
utilizes  a baseline  corresponding  to  current  on-line 
workloads  at  24  bases.  The  monthly  analysis  uses  baseline 
data  projected  by  CAPS  Report  Number  Nine  for  June,  1976, 
which  presumably  accounts  for  the  incorporation  of 
anticipated  new  systems  prior  to  that  time.) 
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